home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
cat
/
cat-minutes-92nov.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
10KB
|
253 lines
Editor's Note: Minutes received 11/3/92
CURRENT_MEETING_REPORT_
Reported by John Linn/DEC
Minutes of the Common Authentication Technology Working Group (CAT)
The CAT Working Group met for one session at the November 1992 IETF.
Primary discussion topics were:
o Status of documents.
o Future work items and issues.
o Token representation and integration.
o FTP security.
Status of Documents
Steve Crocker stated his belief that the GSS-API and associated C
bindings Internet-Drafts were ready for advancement to Proposed Standard
RFCs, and that he would recommend this action shortly. The Kerberos V5
Internet-Draft is pending certain local and specific edits, and is to be
included in the same advancement recommendation. Despite the fact that
Kerberos is the only CAT technology visibly under active development and
support at this time, it was still viewed as a desirable goal that
applications use CAT/GSS-API rather than mechanism-specific interfaces
so as to support future portability.
Future Work Items and Issues
Ted Ts'o led a discussion suggesting future work items and issues for
CAT. He divided client applications for authentication services into
four groups:
1. Datagram protocols, generally (e.g., SNMP) not viewed as a good fit
for CAT, though better suitability to other connectionless
protocols was considered as a possibility.
2. Store-and-forward protocols, also not viewed as a good fit for CAT.
3. Stream protocols (e.g., Telnet, rpc, lpr, NNTP), considered by Ted
as the best-fitting candidates for CAT usage.
4. Multiple-stream protocols (e.g., FTP), with suitability not
evaluated.
His list of thoughts on future work included [with editor's annotations
in square brackets]:
1
o A need for better [more complete and fully-tested] GSS-API clients
and mechanism implementations, e.g., to implement rlogin with less
reliance on local or mechanism-specific routines in addition to
GSS-API.
o Development of an easy-to-use layer overlaid atop GSS-API to embody
token-passing, analogous to Kerberos's krb_sendauth.
Ted's list of issues and near-term action recommendations was as
follows:
o Negotiation of mechanisms: recognized as important in the eventual
term, but not needed in the near term, given a presumption that
GSS-API callers (in an environment with only a limited number of
mechanisms in use) would not be burdened by a requirement to pass
in explicit mechanism type specifiers.
o Strength ranking of mechanisms: as with negotiation, not needed at
first.
o Naming: generalized translation between types not needed, but a
canonical flat ASCII representation was desirable for ACLs, etc.
Internationalization was recognized as an issue here, with a
character set selection tag being requested. The long-requested
and as-long-frustrated desire for a unifying Internet naming
framework also arose as an issue here.
o Infrastructure requirements: given that many sites don't want to
pay the prices attendant to use of Kerberos, SPX, or similar
cryptographic mechanisms, peer-peer key/password exchange and
non-disclosing password systems should be considered as CAT
mechanisms. An issue here is the fact that such lower-function
mechanisms don't generally authenticate principals in terms of
global names; use of an interface facility [e.g., a name type tag]
to distinguish local from global names is a partial approach to the
issue. Many lower-function mechanisms do not yield session keys
for per-message protection as a result of authentication, but
mechanisms with this characteristic are accommodated with existing
interface indicators.
Availability of a Kerberos V4 GSS-API implementation would be
convenient; while some activities had been undertaken to this end in
previous years, no complete implementation compatible with current
specifications is known to exist. The GSS-API modules within the
Kerberos V5 implementation (as of the re- cent Beta 2 release) have been
unit tested, and code exists to support all calls, but have not been
linked and tested with a sample client. Ted Ts'o indicated that he
would like to coor- dinate with anyone interested in performing this
testing, but that he cannot himself provide the resources needed to
develop or carry out the tests in the near future; Steve Lunt expressed
2
interest in this activity.
Token Representation and Integration
The present Kerberos V5 GSS-API implementation includes tagging
facilities on its tokens, but (unsurprisingly, given the order of
events) the tags do not include the object identifier recently assigned
to Kerberos by the IANA and to be included in the upcoming revision to
the Kerberos specification. As a goal, it was agreed desirable that
applications into which authentication is being newly integrated should
use OID-identified mechanism tags. It was noted that use of ASN.1 in
tagging should be constrained (and, in the GSS-API appendix's
recommendation, is constrained to X.509-DER) so that the use of a fully
general ASN.1 parser is not required; further clarification on the
encoding conventions and their processing requirements was requested.
Ted Ts'o suggested development of a generic ``plug-in'' authentication
protocol layered on GSS-API, to be embedded within applications which
are built over stream-oriented communications. NNTP was specifically
cited as an example; Telnet (given the fact that it acts itself as a
sophisticated stream manager and is oriented to transfer of data
elements within options) was not considered as a customer for this
proposed technology and would be more appropriately served by calling
CAT directly. In the ``plug-inx'' approach, a stream would be
established by the application and then handed over for use by the
authentication protocol while authentication tokens were exchanged.
Subsequent to token exchange, within which mechanism negotiation could
also be incorporated, the stream could (optionally) either be handed
back to the application or the application's communications could be
encapsulated and thereby protected by the ``plug-in'' protocol. The
ability to reinitiate the ``plug-in'' protocol on an
already-authenticated stream, thereby accomplishing reauthentication,
was requested in discussion and considered to be supportable.
The format of CAT tokens was not perceived as a particularly hard issue
from the viewpoint of caller protocols; the prospect the token exchanges
in the course of carrying out GSS-API continuation scenarios raises
qualitatively different complexity to callers, which use of the
``plug-in'' could simplify. It was observed that existing mechanisms
involve exchange of no more than two tokens, one from an initiator to a
target and a second returned from the target to the initiator, and that
perhaps the most likely scenario in which need for longer exchanges
might arise would be design of a ``negotiated'' mechanism in which
authentication elements were preceded by tokens transferred in order to
establish a mechanism shared between peers.
FTP Security
At the end of the meeting, Sam Sjogren led a brief discussion on
security for FTP, a topic for which he has established a discussion
group. Interest exists in Kerberized FTP in order to eliminate
transmission of cleartext passwords across networks. The FTP
3
specification states that FTP's control connection ``follows Telnet
protocol'', but is silent about use of Telnet options on the control
connection and it was believed that at least most FTP implementations
would not accept Telnet options on an FTP control port. The FTP
specification also states that data elements in FTP commands are usually
to be interpreted by humans, but informal communication with Jon Postel
suggests that he would not oppose the inclusion of encoded data intended
for machine interpretation (e.g., cryptographic authentication tokens)
so long as the data elements' contents were properly specified. It was
suggested that authentication information for an FTP control connection
could be represented either through use of the Telnet authentication
option (if Telnet options are found to be supported or easily
supportable within FTP) or by direct calls to CAT and textual encoding
of CAT tokens.
In addition to security on FTP's control connection, there was also
interest in protecting the data connection, most efficiently in a block
mode. Any such protection would need to be compatible with the variety
of transfer modes supported within FTP.
Actions
Ted Ts'o plans further work on documenting the stream-oriented
``plug-in'' overlay.
Neil Haller plans further work on integrating a lower-function
authentication mechanism, probably to be based on the S/key technology,
under the GSS-API.
John Linn plans further work on documenting token encoding conventions
and their attendant requirements.
Attendees
David Conklin conklin@jvnc.net
Stephen Crocker crocker@tis.com
Cathy Cunningham cmc@microcom.com
Art Dertke dertke@gateway.mitre.org
William Edison
Richard Graveman rfg@ctt.bellcore.com
Neil Haller nmh@thumper.bellcore.com
Ken Hirata khirata@emulex.com
Russell Housley Housley.McLean_CSD@Xerox.Com
Frank Kastenholz kasten@ftp.com
David Katinsky dmk@rutgers.edu
John Kunze jak@violet.berkeley.edu
Paul Lambert paul_lambert@email.mot.com
John Linn linn@erlang.enet.dec.com
Steven Lunt lunt@bellcore.com
Mohammad Mirhakkak mmirhakk@mitre.org
Clifford Neuman bcn@isi.edu
Hilarie Orman ho@cs.arizona.edu
4
Paul Sangster sangster@ans.net
Sam Schaen schaen@mitre.org
Sam Sjogren sjogren@tgv.com
Tang Tang tt@virginia.edu
John Vollbrecht jrv@merit.edu
Chuck Warlick warlick@theophilis.nsfc.nasa.gov
Daniel Woycke woycke@smiley.mitre.org
5